(1) Field of the Invention
The present invention relates to a method of providing information and to an information providing system that provide information via a network such as the Internet. In particular, the present invention relates to an information providing apparatus and an information providing system that can perform transactions for information with high security.
(2) Description of the Prior Art
As Internet usage has expanded into ordinary households, transactions, such as Internet auctions, where individual users buy and sell goods via a network have become increasingly common. It has also become common for individual users to develop commercial sites for music contents, images, software, etc., that have been created by the user himself or herself so that such contents can be bought and sold by individual users via the network. When contents are bought and sold, the users involved in the transaction are not able to see or meet the unknown person with whom they are dealing, which can be a source of anxiety for both users. This is to say, the content provider may be anxious about whether the content receiver will definitely pay the suitable amount after receiving the content. On the other hand, the content receiver may be anxious about whether the content will be properly sent after the content receiver has paid.
Prior Art Example
A technique for solving the problem described above has already been proposed. This technique is disclosed in the document ┌N. Asokan, V. Shoup, M. Waidner, “Asynchronous Protocols for Optimistic Fair Exchange,” (1998 IEEE Security and Privacy Symposium), for example.
In this prior art example, the information provider transmits content data iO and a provider certificate, which confirms that this content data iO is from this information provider, to the receiver. In exchange for this content data iO and the provider certificate, the receiver transmits a receipt showing that the content data iO has been properly received to the information provider. When the exchanging of the content data iO and the receipt is not performed successfully between the information provider and the receiver, either of two situations, “the content data iO was provided by the information provider but the receiver cannot receive it” and “the receiver cannot receive the content data iO” is possible. In this case, the information provider or the receiver can provide the data that was exchanged between the information provider and the receiver to a dispute resolution agency and issue a resolution request. The dispute resolution agency then checks the data that is provided and judges whether the issued request is legitimate. On judging that the request is legitimate, the dispute resolution agency resolves the problem by making it possible for the information provider to receive the receipt or by making it possible for the receiver to receive the content data. This prior art is described in detail below.
Exchange Protocol
FIG. 11 shows the composition of the “exchange protocol” that is the protocol used to exchange the content data and the receipt between the information provider and the receiver. The procedure of this exchange protocol is described below in accordance with FIG. 11.
Initial Settings
The information provider and the receiver are assumed to each have generated a pair of a public key and a secret key in accordance with a public key encryption method and to have made their respective public keys available. The dispute resolution agency is also assumed to have generated a public key and secret key pair and to have made its public key available.
(0) Request for the Provision of Information
First, the receiver requests the information provider to provide information. After this request, each party obtains the other party's public key.
(1) Generation of the Data me1
The information provider generates data me1 including the related party data, dispute resolution data, first provider certifying data, and receipt text data that are described below.
Related Party Data
The related party data is data generated by linking a public key VO of the information provider, a public key VR of the receiver, and a public key T of the dispute resolution agency. This is to say, the related party data is generated according to expression (1) below.VO∥VR∥T  (1)
Here, the operator “∥” represents the linking of data.
Dispute Resolution Data
The dispute resolution data is generated by linking the content data iO, second provider certifying data keyO, the public key VO of the information provider, and the public key VR of the receiver and then encrypting the linked data using the public key T of the dispute resolution agency. This is to say, the dispute resolution data is generated according to expression (2) below.EncT(iO∥keyO∥VO∥VR)  (2)
Here, the term “EncT(X)” represents the result of encryption of the input data X using the public key T. The second provider certifying data keyO is data that is generated at random by the information provider.
First Provider Certifying Data
The information provider generates the first provider certifying data hO from the second provider certifying data keyO mentioned above in accordance with expression (3) below.hO=HASH (keyO)  (3)
Here, HASH (X) represents the value of a hash function for input data X, which is to say, the hash value for the input data X.
Receipt Text Data
The information provider generates the receipt text data receipt_tex in which a content of the information received by the receiver, the sum paid in exchange for the information, the date and time of receipt, etc., are written.
The information provider uses the information provider's secret key to sign the data generated by linking the four pieces of data mentioned above and thereby generates the data me1. This is to say, the data me1 is generated in accordance with expression (4) below.
                              me          ⁢                                          ⁢          1                =                  SigO          ⁡                      (                          VO              ⁢                                              VR                                            ⁢              T              ⁢                                                                                    EncT                    (                    iO                                                        ⁢                                      key                    ⁢                    O                                    ⁢                                                          VO                                                        ⁢                  VR                                )                            ⁢                                              hO                                            ⁢              receipt_tex                        )                                              (        4        )            
Here, SigO(X) represents the result (signed text) generated when the input data X is signed using the secret key of the information provider.
(2) Transmission of the Data me1
The information provider transmits the data me1 generated in process (1) to the receiver.
(3) Checking the Data me1 and Generation of Data me2
Based on the received data me1, the receiver confirms whether the signature of the information provider, the related party data (VO, VR, T), and the receipt text data receipt_tex are correct, and generates the data me2 only when such data are correct. When any of the data above is not correct, the receiver cancels the protocol. The data me2 includes consent data me1 generated as shown below, and first receiver data.
Consent Data me1
The consent data me1 is the same as the data me1 sent from the information provider.
First Receipt Data
The receiver randomly generates second receipt data keyR, and generates first receipt data hR according to expression (5) below.hR=HASH(keyR)  (5)
The hash function HASH(X) shown in expression (5) is the same as the hash function HASH(X) shown in expression (3).
In accordance with expression (6) below, the receiver links the consent data me1 and the first receipt data hR and signs the resulting data using the secret key of the receiver, thereby generating the data me2.me2=SigR(me1∥hR)  (6)
Here, the term “SigR(X)” represents the signing of input data X using the secret key of the receiver.
(4) Transmission of the Data me2
The receiver transmits the data me2 generated in process (3) to the information provider.
(5) Cancellation Protocol when the Data me2 Does Not Arrive
When the data me2 that should have been transmitted from the receiver has not been received within a predetermined period, or when a retransmission request has been outputted for the data me2 in process (6) described below and the retransmission of the data me2 from the receiver has not been performed within a predetermined period, the information provider cancels the subsequent processing and executes the “cancellation protocol” described below. When the information provider receives the data me2 within the predetermined period, the process (6) below is executed.
(6) Checking of the Data me2 and Generation of Data me3
The information provider confirms whether the signature of the receiver and the consent data me1 are correct for the received data me2 and generates the data me3 only when such data are correct. When any of such data is not correct, the information provider requests the retransmission of the data me2 and the control returns to process (5). The data me3 includes the content data iO shown below and the second provider certifying data keyO.
Content Data iO
The content data iO is the content data that the information provider has promised to provide to the receiver.
Second Provider Certifying Data
The second provider certifying data keyO is the same as the second provider certifying data keyO generated in process (1).
The data generated by linking the above data is set as the data me3. This is to say, the data me3 satisfies the relationship shown in the expression (7) below.me3=iO∥keyO  (7)(7) Transmission of the Data me3
The information provider transmits the data me3 generated in process (6) to the receiver.
(8) Execution of the Receiver Dispute Resolution Protocol when the Data me3 Does Not Arrive
When the data me3 that should have been transmitted from the information provider has not been received within a predetermined period, or when a retransmission request has been outputted for the data me3 in process (9) described below and the retransmission of the data me3 from the information provider has not been performed within a predetermined period, the receiver cancels the subsequent processing and executes the “receiver dispute resolution protocol” described below. When the information provider receives the data me3 within the predetermined period, the process (9) below is executed.
(9) Checking of the Data me3 and Generation of Data me4
The receiver confirms whether the content data iO and the second provider certifying data keyO in the received data me3 are authentic. The authenticity of the second provider certifying data keyO is checked by confirming whether the relationship shown in expression (8) below is established with the first provider certifying data hO included in the data me1 received in process (3).hO=HASH(keyO)  (8)
The receiver performs the above confirmation and generates the data me4 only when the data me3 is judged to be authentic. When the data me3 is not judged to be authentic, the receiver requests the information provider to retransmit the data me3, and the control returns to process (8). The data me4 is the second receiver data keyR that was generated in process (3) as shown in expression (9) below.me4=keyR  (9)(10) Transmission of the Data me4
The receiver transmits the data me4 generated in process (9) to the information provider.
(11) Execution of the Provider Dispute Resolution Protocol when the Data me4 does not Arrive
When the data me4 that should have been transmitted from the receiver has not been received within a predetermined period, or when a retransmission request has been outputted for the data me4 in process (12) described below and the retransmission of the data me4 from the receiver has not been performed within a predetermined period, the information provider cancels the subsequent processing and executes the “provider dispute resolution protocol” described below. On receiving the data me4 within the predetermined period, the information provider executes the process (12) below.
(12) Checking of the Data me4
Based on the received data me4, the information provider confirms whether the second receiver data keyR is authentic. The authenticity of the second receiver data keyR is checked by confirming that the relationship shown in expression (10) below is established with the first receiver data hR included in the data me2 received in process (5).hR=HASH (keyR)  (10)
When the above relationship is established, the exchange protocol ends successfully. At this point, the receipt received by the information provider is the data me2 and the data me4. A third party who is neither the information provider nor the receiver and is impartially positioned between them confirms the signature of the data me2 and then confirms whether the relationship shown by expression (11) below is satisfied for the first receipt data hR included in the data me2 and the second receipt data keyR included in the data me4.hR=HASH (keyR)  (11)
The third party also checks the content of the receipt based on the receipt text data receipt_tex included in the agreement data me1 included in the data me1 obtained from the data me2.
On the other hand, the receiver receives the content data iO.
Cancellation Protocol
The cancellation protocol is executed by the information provider when the data me2 that should have been transmitted from the receiver has not arrived in process (5) in the exchange protocol. FIG. 12 shows the procedure of the cancellation protocol. The following describes the procedure of the cancellation protocol using FIG. 12.
(1) Transmission of Data ma1
The information provider generates the data ma1 by signing data produced by linking the data “cancel” with the data me1 using a secret key of the information provider, and transmits the data ma1 to the dispute resolution agency.ma1=SigO(“cancel”∥me1)  (12)
Here, the data “cancel” by which the information provider data requests the dispute resolution agency to cancel the exchange protocol. The data me1 is transmitted by the information provider to the receiver in process (2) of the exchange protocol.
(2) Searching the Dispute Resolution List
After verifying the signature of the information provider applied to the transmitted data ma1, the dispute resolution agency then checks whether the data me1 included in the data ma1 is registered in the dispute resolution list, and depending on the result of this checking, executes either of the processes (A) and (B) that are described below. The dispute resolution list is a list showing whether a dispute has been resolved due to the provider dispute resolution protocol being requested by the information provider or the receiver dispute resolution protocol being requested by the receiver.
(A) When the Data me1 is not Registered in the Dispute Resolution List
The dispute resolution agency judges that dispute resolution has not been performed for the transaction for which the cancellation request was issued. The dispute resolution agency adds the received data me1 to the cancellation list. In addition, in accordance with expression (13) below, the dispute resolution agency generates data ma2 by linking “cancelled” data, which certifies that the transaction has been cancelled, with the data ma1, which was sent from the information provider in process (1), and signing the data produced as a result with the secret key of the dispute resolution agency. The dispute resolution agency then transmits the data ma2 to the information provider. The cancellation list is a list showing whether a transaction has been cancelled due to the information provider requesting the cancellation protocol.ma2=SigT(“cancelled”∥ma1)  (13)
Through this process, the information provider can obtain a certificate showing that the transaction identified by the data me1 included in the data ma1 has been cancelled.
(B) When the Data me1 is Registered in the Dispute Resolution List
The dispute resolution agency judges that the dispute resolution has already been performed for the transaction for which the cancellation request was issued, and sends “dispute resolved” data, which shows dispute resolution has already been performed for this transaction, to the information provider as the data ma2.
Provider Dispute Resolution Protocol
The provider dispute resolution protocol is executed by the information provider when the data me4 that should have been transmitted from the receiver has not arrived in process (11) in the exchange protocol. FIG. 13 shows the procedure of the provider dispute resolution protocol. The following describes the procedure of the provider dispute resolution protocol using FIG. 13.
(1) Transmission of Data mr1
The information provider generates data by linking the content data iO that was transmitted in process (7) of the exchange protocol and the second provider certifying data keyO to the transaction certifying data described below, and transmits this data to the dispute resolution agency as the data mr1. The transaction certifying data is data generated by linking a public key VO of the information provider and the data me1 and data me2 that were respectively handled by processes (2) and (4) of the exchange protocol. This is to say, the data mr1 is generated according to expression (14) below.mr1=VO∥me1∥me2∥iO∥keyO  (14)(2) Searching the Cancellation List
The dispute resolution agency checks whether the data me1 included in the transmitted data mr1 is registered in the cancellation list, and depending on the checking result, executes either of the processes (A) and (B) that are described below.
(A) When the Data me1 is Registered in the Cancellation List
The dispute resolution agency judges that the transaction for which a dispute resolution request has been issued has been cancelled and transmits “cancelled” data showing that the transaction has already been cancelled to the information provider as data mr2.
(B) When the Data me1 is not Registered in the Cancellation List
The dispute resolution agency judges that the transaction for which a dispute resolution request has been issued has not been cancelled. Also, the dispute resolution agency adds the data me1 included in the data mr1 to the dispute resolution list. In addition, the dispute resolution agency generates receipt certifying data mr2 in accordance with expression (15) below by linking “reception certified” data showing a certifying of reception by the dispute resolution agency and the data mr1 transmitted from the information provider in process (1) and signing the linked data with the secret key of the dispute resolution agency, and transmits this data mr2 to the information provider.mr2=SigT(“reception certified”∥mr1)  (15)
Due to this process, the transaction identified by the data me1 included in the data mr1 is performed and the information provider can obtain a certificate showing that the content data iO was received by the receiver.
Receiver Dispute Resolution Protocol
The receiver dispute resolution protocol is executed by the receiver when the data me3 that should have been transmitted from the information provider has not arrived in process (8) in the exchange protocol. FIG. 14 shows the procedure of the receiver dispute resolution protocol. The following describes the procedure of the receiver dispute resolution protocol using FIG. 14.
(1) Transmission of Data mr1
The information provider generates data mr1 by linking transaction certifying data described below to the second receipt data keyR that was generated in process (3) of the exchange protocol, and transmits the data mr1 to the dispute resolution agency. The transaction certifying data is data produced by linking a public key VR of the receiver and the data me1 and data me2 that were respectively handled by processes (2) and (4) of the exchange protocol. This is to say, the data mr1 is generated according to expression (16) below.mr1=VR∥me1∥me2∥keyR  (16)(2) Searching the Cancellation List
The dispute resolution agency checks whether the data me1 included in the transmitted data mr1 is registered in the cancellation list, and depending on the checking result, executes either of the processes (A) and (B) that are described below.
(A) When the Data me1 is Registered in the Cancellation List
The dispute resolution agency judges that the transaction for which a dispute resolution request has been issued has already been cancelled and transmits “cancelled” data showing that the transaction has already been cancelled to the information provider as data mr2.
(B) When the Data me1 is not Registered in the Cancellation List
The dispute resolution agency judges that the transaction for which a dispute resolution request has been issued has not been cancelled. The dispute resolution agency also extracts dispute resolution data EncT (iO∥keyO∥VO∥VR) from the data me1 included in the data mr1, decrypts this using the secret key of the dispute resolution agency, and obtains the decrypted data iO∥keyO∥VO∥VR. In addition, the dispute resolution agency checks whether the public key VO of the information provider and the public key VR of the receiver that are included in the decrypted data respectively match the public key VO of the information provider and the public key VR of the receiver that were included in the related party data extracted from the data me1. When any of the keys out of these two types of public key do not match, the dispute resolution agency cancels the subsequent processing and does not perform dispute resolution. When both types of key match, the dispute resolution agency transmits the data mr2, which is generated by linking the content data iO included in the decrypted data and the second provider certifying data keyO as shown in expression (17) below, to the receiver.mr2=iO∥keyO  (17)
In this way, the receiver can receive the content data iO, so that the dispute is resolved.
As described above, in this prior art example, even if a problem occurs during a transaction, the dispute resolution agency executes processing that has the transaction completed successively. This means that both the information provider and the receiver can exchange the content data and the receipt without either party feeling that the exchange has been unfair.
This is to say, when the information provider has transmitted the data me1 to the receiver but cannot receive the data me2 included in the first receipt data hR from the receiver, the information provider executes the cancellation protocol. By doing so, the information provider requests the dispute resolution agency to cancel the transaction and so can have the transaction cancelled.
Also, when the information provider has transmitted the content data iO to the receiver but cannot receive the second receipt data keyR, the information provider executes the provider dispute resolution protocol. By doing so, the information provider can receive the receipt certifying data mr2 from the dispute resolution agency in place of the second receipt data keyR. By using this receipt certifying data mr2, the information provider can prove to a third party that the receiver has received the content data iO.
In addition, when the receiver has transmitted the data me2 including the first receipt data hR to the information provider but cannot receive the content data iO, the receiver executes the receiver dispute resolution protocol. By doing so, the receiver can receive the content data iO from the dispute resolution agency.
However, in this prior art example, there is the problem that the information provider is capable of the illegal act described below.
The following describes an illegal act by the information provider during the exchange protocol shown in FIG. 11.
The information provider generates the dispute resolution data EncT (iO∥keyO∥VO∥VR) using the content data iO in process (1) of the exchange protocol. When doing so, the information provider uses fake data as the content data iO. The receiver receives the data me1 including the dispute resolution data EncT (iO∥keyO∥VO∥VR) in process (2) of the exchange protocol. However, the dispute resolution data EncT (iO∥keyO∥VO∥VR) is encrypted using the public key of the dispute resolution agency, so that at this point, the receiver cannot verify the content of the content data iO. This means that the receiver transmits the data me2 to the information provider in process (4) of the exchange protocol.
After receiving the data me2 in process (4) of the exchange protocol, the information provider does not transmit the content data iO to the receiver, but instead executes the provider dispute resolution protocol.
At this point, in process (1) of the provider dispute resolution protocol shown in FIG. 13, the content data iO included in the data mr1 that the information provider transmits to the dispute resolution agency is the same as the fake data that the information provider used in process (1) of the exchange protocol to generate the dispute resolution data. Since the information provider does not execute the cancellation protocol, the data me1 is not registered in the cancellation list and the transaction is recognized as not having been cancelled. This means that process (B) of the provider dispute resolution protocol is executed and the information provider can illegally obtain the receipt certifying data mr2 from the dispute resolution agency.
On the other hand, a receiver who cannot receive the data me3 executes the receiver dispute resolution protocol, but since the content data iO in the dispute resolution data included in the data me1 is fake, the expected content data is not obtained. As described above, the content data iO is not checked by the dispute resolution agency, so that there is the problem that illegal acts can be performed by the information provider.
At this point, the information provider actually obtains a receipt for the “fake content data”. However, when the information provider bills the receiver based on this receipt, the payment agency merely checks the sum written on the receipt, so that there is no checking of what has been purchased by this sum and of whether the purchased item is genuine. Accordingly, the information provider can illegally collect a payment from the receiver using fake content data. This prior art example was originally conceived as for adaptation in a “recorded delivery”-type service, and in the case of recorded delivery, even if a received content is fake, the receiver only issues a receipt for the fake item, so there is no significant problem. However, when a billing process is performed based on the receipt, the billing should be performed with the content data to which the receipt applies first having been checked for authenticity. However, the billing agency does not go as far as checking whether the content data to which the receipt applies is authentic. This makes it possible for the illegal act described above to succeed.